A database transaction is a group of related updates against a database that form a single “unit of work.” There are basically two types of transactions: “short transactions” and “long transactions.” Short transactions typically take a few seconds or less to complete. A simple example is a bank account transfer, which may involve subtracting the appropriate amount from an entry in one account and adding the same amount to another account. Since this may take a relatively short period of time to complete, the records may be locked while the transaction is in progress to ensure that nobody else is able to change them and create any inconsistencies.
In contrast, a long transaction may take hours, weeks, or months. An example is a transaction within a Geographic Information System (GIS)-a computer-based tool for mapping and analysing spatial data, such as geographic data and engineering designs. During a GIS transaction, an engineer may generate design alternatives or spatial analysts may perform complex “what if” scenarios. Because these transactions may take a long period of time, locking records for an environment with multiple users who need to access the same data is inefficient and counterproductive. Concurrent control becomes a critical issue.
One known method for solving the long transaction problem is version management. A version is a logical copy of the database specific for a small group of users or for a single user without duplication of the data. This allows multiple users simultaneous access to the same data without applying locks to prohibit other users from modifying the same data. A version managed database system maintains these versions and any conflict that arises from them.
A version is a named logical embodiment of a database state distinct from other versions. The number and state of database records visible within a version may change over time. Versions are generally arranged in a tree structure, as depicted in FIG. 1, and any version may be changed by users or processes independently of and without affecting the data visible in another version. It is known in the art to have changes in one version made available to other versions using the processes of reconcile and post.
A state is a labeled snapshot of a version. Each version points to a specific state. Multiple versions may share the same state if desired. If they do, then users may see identical data in both versions. Over time, versions may move from one state to another. As changes are made to a version, its state may change. The states are containers for the changes to the database. As changes are made to a version, the changes are tagged with the appropriate state. Database states are organized as a tree, where the parent/child relationship may be derived from the state lineage. States are not necessarily explicit within all implementations of version-managed databases.
FIG. 1 illustrates these components working together in a version-managed database. V1 is the first version, and S1 is the first state. V1 is set to S1. Then, a change is made to V1. This change is applied to S1, thus creating a new state S2. A new version is created, V2, and is set to S2. Thus, at this time, V1 and V2 are set to S2. Next, V1 changes again, applying the changes to S2 creates a new state, S3. S2, and hence V2, are unchanged by this operation. V3 is created and set to S3. Thus, V3 and V1 are both pointing to S3.
Next, V4 is created, and set to S2. Changes are made to V4, creating a new state derived from S2, called S4. V4 is set to S4. Changes are then made to V3, creating a new state derived from S3 called S5. Changes are next made to V4, creating S6, derived from S4.
Next, V3 is changed, creating S7, derived from S5. A new version, V6, is created, pointing to S7. V6 is changed, creating S8, derived from S7. V6 is changed again, creating S9, derived from S7. V7 is next created, set to S7. Then, V4 is changed, which was pointing to S6 last, creating S10, derived from S6. V7 is then changed, which was last pointing to S7, thus creating a new S11, derived from S7. V7 is changed again, creating S12, then S13. Finally, V6 is changed, creating S14, derived from S9.
This illustration shows the concepts of versions and states and how these two elements interact with each other.
A very common requirement for companies who use these database systems is to be able access the data in multiple, geographically separate locations, as depicted in FIG. 2. Version-managed databases 1a–1d may be connected through a variety of networks 5. This requires a system of replication, where the database is replicated in multiple locations. In such a system, data synchronization management between the databases becomes critical to ensure reliable data at every location.
One such system, “Smallworld 3” from GE Smallworld, Inc., manages the replication and synchronization of version managed databases by relying on a single process to connect live to all of the databases at once in order to synchronize. This single process gains exclusive control of the relevant versions and records in all of the databases being synchronized, thus preventing access to the data during the synchronization process. In the case where the network 5 connecting the version managed databases 1 is unreliable or high-speed communications between database 1 sites is unavailable, single process synchronization may be inefficient.
Accordingly, it is believed that systems and methods for synchronizing replicated version-managed databases would be considered useful.